ShowTable of Contents
Sametime Deployments and Ports to Open in Firewalls
This article provides additional guidance on Sametime and WebSphere Application Server ports to use, and when to include servers and nodes on the same network. Before beginning your deployment, be sure to read the
Sametime Advanced or
Sametime Standard technical documentation for help in planning your deployment.
When you plan a Sametime installation, you need to consider security, the size and scope of your installation, and which firewall ports to open. There are many ways to deploy Sametime, everything from a simple single-machine installation of instant messaging and presence, to a large scale secure, clustered deployment featuring LDAP, web meetings, web meetings that can be accessed by external clients, audio/visual chat, telephone support, mobile and browser client access, and integration with third-party products such as Microsoft Office. There is no "one size fits all" deployment scenario.
The way you deploy Sametime will determine which Sametime ports to use, which WebSphere Application Server ports to use, and which ports to open in the firewalls. Secure deployments use two firewalls, which define three security zones. The inner firewall isolates the organization’s intranet (the most secure zone), and the outer firewall creates a DMZ between the intranet and the Internet (the least secure zone). For example, this illustration shows a large and secure installation where Sametime services are exposed to the Internet but outside the inner firewall:
In this graphic, two firewalls define three security zones. The inner firewall isolates the organization’s intranet (the most secure zone), and the outer firewall creates a DMZ between the intranet and the Internet (the least secure zone).
Deployment of Sametime is always dependent on your company's security requirements, capacity, and the features you want to install. If you only want to allow users within your organization to meet with external users connecting from the Internet, then you would install a Sametime Meetings server outside the inner firewall, or DMZ.
Cells, clustering, and network considerations
WebSphere Application Server uses a Deployment Manager to manage all nodes or servers in a cell. A cell has one Deployment Manager to provide central management and the clustering of servers for high-availability and failover. When servers are installed as part of a Network Deployment in one cell, then it's easy to administer them with the Sametime System Console. Sametime 8.5.2 and newer releases use the Network Deployment method of implementing all servers as Primary Nodes federated to the Deployment Manager of the Sametime System Console in one cell.
Most servers are WebSphere Application Server-based and managed by the Deployment Manager:
- Sametime System Console
- Sametime Meeting Server
- Sametime Proxy Server
- Sametime Media Manager (includes SIP Proxy and Registrar, Conference Manager, Packet Switcher)
- Sametime Advanced Server
- Sametime Bandwidth Manager
- Sametime Gateway Server
A few servers are not managed by a Deployment Manager:
- Sametime Community Server
- Sametime TURN Server
- LDAP
The Sametime System Console is always installed with the Cell Profile by default. Install each new type of server as a Primary Node and allow the installation program to integrate it immediately with the console. See
Clustering Sametime servers for high enterprise availability for more information.
Putting Servers and Nodes in the Same Subnet
Installing Sametime components in the same subnet is preferred but not required in all cases.
When there is clustering, the nodes must be within the same local network. In addition, keeping servers on the same network is a good rule to follow to keep response times between the web client and the servers similar, and also to support livename integration. If there is no livename integration, the requirements are less rigid. It's also a good rule to have all host names similar for session scoping and SSO (LTPA) integration. Finally, being in the same local network helps to prevent delays in communication across components.
For high availability deployments involving the Sametime Media Manager, IBM Load Balancer, and WebSphere Application Server Proxy server, all these components must be on the same subnet within the local network.
Installing and clustering Sametime components across a WAN, especially in Disaster Recovery scenarios where you might have multiple data centers, and mirroring or clustering across the data centers, is not recommended.
Sample components on the same network:
- sysconsole.example.com
- st.example.com
- webchat1.example.com
- webchat2.example.com
- meetings1.example.com
- meetings2.example.com
- meetings3.example.com
- turn.example.com
Small and Highly Secure Deployments
For a small deployment that's very secure, deploy the Sametime servers in the DMZ. With the exception of LDAP and DB2 in the Intranet, install the Sametime Community Server, System Console, Meeting Server, Media Manager, and Proxy Server in the DMZ. Then you only need the firewall ports for LDAP TCP 389 (or 636) and DB2 TCP 50000 or 50001 to be opened from the DMZ to the intranet. You would also need to open the UDP ports from the Media Manager to internal clients in both directions. Establish all other connections from the internet to the DMZ only.
With the Sametime System Console deployed in the DMZ, it can be in the same cell as the Meeting Server, Media Manager, and Proxy Server. The System Console can also serve as the Deployment Manager for any other Sametime servers hosted in the DMZ, so external users can now access the features offered by any Sametime servers that are deployed in the DMZ. Hosting a Sametime Proxy Server in the DMZ enables the awareness feature for external users who attend meetings, hosted on a Meeting Server that is also deployed in the DMZ.
Most of the time clients inside a company must pass through a Network Address Translator (NAT) to get to the Internet. And most of the time users who work from a home office must pass through a NAT-enabled router to get to the Internet. If your users must pass through NAT or a firewall, and you want them to access audio and video, then you need to deploy a TURN server. A TURN is required when direct peer-to-peer communications are not possible.
You also need to open a UDP port range between internal clients and the Media Manager and between the Media Manager and the TURN Server for clients that use audio/video.
Note: If a client is behind an HTTP Proxy Server and access to the Internet is only allowed using Port 80 HTTP or 443 SSL, then Sametime cannot support audio/video.
See
Planning a Sametime TURN Server deployment for more information.
Architecture for small, highly secure deployment with TURN server
IP prerequisites
- A static IP address for each server
- The fully qualified host name of each server registered in DNS (or a hosts file containing IP addresses and fully-qualified host names that is published to all servers)
- A host name in DNS that will be used for load-balancing connections. One host name is required for Meetings, Proxy, Community and each of the Media Server components.
- Internet Control Message Protocol (ICMP) for ping needs to be open between the Sametime System Console and all servers during installation.
Ports
Inside firewall ports to open
- LDAP to Community Server: TCP 389 or 636
- DB2 to System Console, Proxy Server, Meeting Server: TCP 50000 or 50001
- Sametime System Console to all servers: ICMP (for ping)
- Internal clients to Community Server: VP 1533
- Internal Notes client Single Sign On (SSO) to Community Server: VP 1352
- Internal clients to Proxy Server: TCP 80 or 443
- Internal clients to Meeting Server: TCP 80 or 443
- Internal clients to TURN Server: TCP or UDP 3478
- Internal clients to Sametime Media Manager:
- UDP outbound: 42001 to 43000 (audio); UDP 46001 to 47000 (video)
- UDP inbound: 42000 to 43000 (audio); UDP 46000 to 47000 (video)
Outside firewall ports to open
- External clients to TURN Server: TCP or UDP 3478
- External clients to Media Manager: TCP 5081 and 5061
- External clients to Proxy Server and Meeting Server: TCP 80 or 443
Reference
Other Considerations
Configure servers for single sign-on (SSO) as a convenience to users running the Sametime® browser client or the Connect Client. With SSO, users who log in once to any server in the DNS domain. See
Setting up single sign-on (SSO) for Sametime clients. In addition, when using LTPA tokens, make sure you choose the correct SSO domain for your web users.
Proxy Server Edge Deployments
For Proxy Server Edge installations, you must have the same fully qualified host names in intranet and DMZ. The host names used in the intranet must be configured in the public DNS pointing to the public IP address of the server machine in the DMZ hosting the Edge components.
Architecture for all edge components in the DMZ
IP prerequisites
- A static IP address for each server
- The fully qualified host name of each server registered in DNS (or a hosts file containing IP addresses and fully-qualified host names that is published to all servers)
- A host name in DNS that will be used for load-balancing connections. One host name is required for Meetings, Proxy, Community and each of the Media Server components.
- Internet Control Message Protocol (ICMP) for ping needs to be open between the Sametime System Console and all servers during installation.
Ports
Inside firewall ports to open
- Sametime Media Manager to TURN server:
- UDP 49152 to 65535
- UDP outbound: 42001 to 43000 (audio); UDP 46001 to 47000 (video)
- UDP inbound: 42000 to 43000 (audio); UDP 46000 to 47000 (video)
- Sametime Media Server to Sametime SIP Proxy Registrar: SIP 5081 or 5061
- Internal clients to TURN Server: TCP or UDP 3478
- Sametime Meeting Server to WebSphere HTTP Proxy: HTTP 80 or 443
- Sametime Proxy Server to WebSphere HTTP Proxy Server : HTTP 80 or 443
- Sametime Community Server to Sametime Multiplexor: VP 1516
Outside firewall ports to open
- External clients to TURN Server: TCP or UDP 3478
- External clients to Sametime SIP Proxy Registrar: SIP 5081 and 5061
- External clients to WebSphere HTTP Proxy Server: HTTP 80 or 443
- External clients to Sametime Multiplexor: VP 1533
Reference
Large and Highly Secure Deployments
A large and highly secure deployment exposes Sametime services to the Internet by deploying additional Sametime servers, plus the Sametime System Console, in the DMZ. Two firewalls define three security zones. The inner firewall isolates the organization’s intranet (the most secure zone), and the outer firewall creates a DMZ between the intranet and the Internet (the least secure zone). The Sametime System Console is now deployed in the DMZ rather than the intranet, so it can be installed into the same WebSphere Application Server cell as the Meeting Server, Media Manager, Proxy Server, and DB2. The System Console can also serve as the Deployment Manager for any other Sametime servers hosted in the DMZ, so external users can now access the features offered by any Sametime servers that are deployed in the DMZ. For example, hosting a Sametime Proxy Server in the DMZ enables the awareness feature for external users who attend meetings hosted on a Meeting Server that is also deployed in the DMZ
LDAP and the Community Server are in the intranet only. All other servers are duplicated in the DMZ, except for the addition of a TURN server in the DMZ.
Architecture for large, highly secure deployment
Reference
Installing Nodes Outside a Firewall
There are many times when deploying a node outside a firewall is a preferable and valid solution, but it requires a lot of ports to be opened in the firewall. For example, deploying a WebSphere HTTP Proxy server in the Internet to tunnel through the firewall to a server and nodes. It's also an easy way to give extranet access to the mobile users when on the road.
Installing nodes across a firewall requires that ports be opened so that the nodes can communicate with each other. At installation, WebSphere Application Server assigns ports dynamically. Before you begin deployment, open a range of ports (7000 to 9999) between the nodes and the deployment manager in the Sametime System Console. After installation and configuration are done, open the Integrated Solutions Console (see steps below) to determine the exact ports that are being used. Then specifically open those ports in firewalls as needed. Keep in mind that sometimes port values change during the installation, configuration, and clustering processes, so it's difficult to be prescriptive about ports to open.
Note: SOAP ports 8879, 8880, 8881, 8882 and so on, can be used by other components like antivirus software. If you have this port conflict, then one of the port assignments for WebSphere Application Server or the antivirus software needs to be changed.
After installation, close down the firewall by checking which ports the WebSphere Application Server is using and monitor the firewall.
How to Determine WebSphere Application Server Ports
The following screen shots show the default ports for a single appserver on a standalone node where no other appservers have been deployed. The ports should be looked up active in the configuration for each node/host to insure accuracy. Use the
productConfig.properties file to verify port numbers for WebSphere Application Server-based components. The productConfig.properties file contains settings used to register an IBM® Sametime® servers running on IBM WebSphere® with the Sametime System Console. See
productConfig.properties file for WebShere-based servers for a good example.
1. Log on to the Integrated Solutions Console, and click System administration > Deployment manager, then click Ports.
Other Deployment Managers may use alternate ports, but the following ports are the defaults for the Sametime System Console when used as a Deployment Manager.
2. Open all ports from remote nodes to the following ports in WebSphere Application Server:
3. From the Integrated Solutions Console, and click System administration > Node agents.
4. In this example, click the first nodeagent to view ports from the Deployment Manager to the node agents:
5. Click Ports:
As a rule, the Deployment Manager talks to the nodeagents, the nodeagents talk to the servers that are on their nodes. There is nothing to open between nodeagents and their servers.
Between WebSphere Application Server Proxies and the members of the clusters they are fronting, you need to open these ports:
For an HTTP Proxy, view the port numbers in WC_defaulthost and WC_defaulthost_secure.
For a SIP Proxy, view the port numbers in SIP_DEFAULTHOST and SIP_DEFAULTHOST_SECURE
WebSphere Application Server Ports
Log in to the Integrated Solutions Console for the WebSphere Application Server-based Sametime application server.
Click Applications Servers-> STMeetingServer or STMediaSever or STproxyServer -> Ports.
For port values, see
Finding ports for WebSphere Application Server-based applications.